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ABSTRACT 

Department  of  Defense  (DoD)  Open  Systems  Architecture  (OSA)  policies  are  supposed  to 
enhance  acquisition  reform  to  ensure  competition  for  better  pricing  as  dictated  by  the  Weapons 
Systems  Acquisition  Reform  Act  of  2009.  However,  the  competition  for  better  pricing  using 
OSA  does  not  necessarily  drive  innovation  that  addresses  increasing  system  complexity.  In  the 
face  of  increasing  system  complexity,  uncertain  security  profiles,  and  a  challenging  budget 
environment,  the  defense  acquisition  process  and  SE  efforts  need  to  work  in  concert  to  produce 
defense  systems  that  reduce  time  to  deployment  and  are  more  adaptable.  We  look  to  complex 
adaptive  systems  (CAS)  and  evolutionary  theory  for  strategies  for  competition  using  methods 
from  dynamical  systems  and  population  genetics.  The  key  insight  of  evolutionary  theory  is  that 
many  behaviors  involve  the  interaction  of  multiple  entities  in  a  population,  and  the  success  of 
any  one  of  these  entities  depends  on  how  its  behavior  interacts  with  that  of  others.  Furthermore, 
we  investigate  potential  for  bidirectional  coupling  between  population  density  (market  size)  and 
the  evolution  of  an  emergent  trait  such  as  competition.  We  propose  the  use  of  the  Component 
Competition  Readiness  Level  (CCRL)  metrics  which  define  and  measure  competition  readiness 
to  promote  agility  in  the  complex  dynamics  of  the  acquisition  processes. 

INTRODUCTION 

“If  you  want  to  build  a  ship  don ’t  herd  people  together  to  collect  wood  and  don  ’ t  assign  them 
tasks  and  work,  but  rather  teach  them  to  long  for  the  endless  immensity  of  the  sea.  ”  — Antoine 
de  Saint-Exupery,  Wisdom  of  the  Sands 

In  the  last  couple  of  decades  the  nature  of  the  threat  faced  by  our  nation  has  changed 
dramatically.  A  Booz  Allen  Hamilton  report1  points  out  that  the  United  States  is  increasingly 
facing  threats  that  are  surmountable,  but  that  are  highly  unpredictable.  The  unpredictable, 
asymmetrical  nature  of  the  threats  coupled  with  the  accelerated  pace  of  change  in  the  security 
landscape — such  as  new  and  emerging  foreign  powers,  non-state  actors  (Figure  1)  with 
increasingly  destructive  enabling  technologies  — are  generating  pressures  on  the  way  in  which 
the  DoD  fields  defense  systems. 
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Figure  1.  Transformative  Forces  in  the  DoD  Acquisition  Landscape1 

The  DoD  finds  itself  operating  in  a  world  that  has  become  increasingly  more  complex  and 
unpredictable  while  shifting  “to  a  smaller,  leaner  force  that  is  agile,  flexible,  and  ready  to  deploy 
quickly”4  with  “strategic  agility.”5  These  transformative  forces  have  led  to  studies  such  as  the 
System  2020 1  initiative  and  the  National  Defense  Industrial  Association  (NDIA)  Final  Report  of 
the  Model  Based  Engineering  (MBE)  Subcommittee ,6  The  studies  highlight  the  need  for  a  SE 
transformation  that  could  enable  the  DoD  “to  design  and  build  an  entirely  new  class  of  adaptive 
systems  that  allow  the  Department  to  operate  with  far  greater  speed  and  agility.”1  The  same 
trends  are  highlighted  in  the  context  of  information  technology  (Figure  2),  which  provides  as 
much  as  80  percent  of  weapon  system  functionality. 
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Figure  2.  The  Perfect  IT  Storm — “Rate  of  Technology  Change  Is  Increasing  as  is  the 
Interconnected  Nature  of  Systems  While  Timelines  are  Shrinking.”7 

The  current  response  to  a  more  complex  and  unpredictable  world  has  been  to  field  more 
complex  defense  systems.  Many  studies  ’  have  documented  the  increasing  complexity  of 
defense  systems  (Figure  3).  However,  the  increase  in  complexity  has  produced  an  increase  in 
risk  for  system  development  such  that  the  time  to  field  and  the  cost  of  new  systems  are  not 
acceptable.  Traditional  SE  processes  such  as  MIL-STD-499A  are  unable  to  deal  with  the  Nm 
growth  in  system  complexity,  where  N  represents  components  and  m  is  the  interactions  between 
components.  The  traditional  system  integration  approaches  are  unable  to  deal  with  the  power-law 
growth  curve  (just  imagine  doing  first  order  testing  on  N  components  with  m  connections,  not  to 
mention  second-order  effects). 
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Figure  3.  Variability  in  the  Way  Different  Industries  Have  Managed  Growth  in  Complexity.9 

The  System  2020  study,  mentioned  earlier,  has  proposed  many  system  engineering  (SE) 
approaches  such  as  MBE,  Platform  Based  Engineering  (PBE),  and  Capability  on  Demand  (COD) 
to  modernize  the  discipline.  The  key  insight  of  the  System  2020  study  is  to  leverage  modularity 
and  reusability  to  produce  agility  and  adaptability. 

The  increasing  complexity  of  defense  systems  has  also  contributed  to  the  cost  of  defense 
system  acquisition.  In  response,  Congress  passed  the  Weapon  Systems  Acquisition  Reform  Act 
of  2009  with  the  stated  goal  to  ensure  competition  for  better  pricing.  The  DoD  acquisition 
community  has  also  been  driving  policy  reforms  for  better  buying  power  through  open 
architecture. 

The  purpose  of  this  paper  is  not  to  propose  another  SE  approach.  We  derive  insights  based  on 
our  understanding  of  complex  systems  and  social  networks  for  a  marketplace  driven  by 
competition  that  can  adapt  to  produce  cost-effective  defense  systems  and  that  is  able  to  evolve 
with  new  emerging  threats. 

BACKGROUND 

The  Under  Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics  (USD  AT&L), 
Honorable  Frank  Kendall,  introduced  Better  Buying  Power  (BBP)  2.0  in  his  memorandum  of 
November  13,  2013,  to  acquisition  professionals  across  the  DoD.10  BBP  (http://bbp.dau.mik)  is 
now  part  of  the  DoD’s  mandate  to  do  more  without  more  by  implementing  best  practices  in 
acquisition.  That  memorandum  was  subsequently  followed  by  another  on  April  24,  2013,  which 
provided  the  implementation  directive  for  BBP  2.0. 11  The  latest  BBP  direction  comes  nearly 
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three  years  after  the  initial  BBP  1.0.  In  both  cases  the  intent,  as  expressed  by  USD  AT&L,  is  to 
obtain  greater  efficiency  and  productivity  in  defense  spending  by  pursuing  an  initial  set  of 
initiatives  in  five  areas.  With  the  issuance  of  the  latest  BBP  2.0  directive,  BBP  identifies  seven 
areas  of  focus  that  group  a  set  of  36  initiatives  to  drive  affordability  in  defense  procurement  and 
improve  defense  industry  productivity.  One  of  the  directives  promoting  competition  includes 
enforcement  for  OSA  and  management  of  technical  data  rights  to  strengthen  the  Defense 
Department’s  buying  power,  improve  industry  productivity,  and  provide  affordable,  value-added 
military  capability  to  the  warfighter. 

OSA  incorporation  into  Area  5,  “Promoting  effective  competition,”  represents  a  milestone 
unto  the  topic  itself.  Competition  is  considered  by  Defense  leadership  as  the  single  most 
powerful  tool  available  to  the  Department  to  drive  productivity.  For  products,  acquisition 
strategies  must  address  how  program  managers  will  realize  and  maximize  competition  from 
program  inception  through  sustainment. 

OSA  merges  technical  architecture  with  an  open  business  model.  Technical  architecture 
defines  open  standards,  published  key  interfaces,  and  full  design  disclosure  to  produce  modular, 
loosely  coupled  but  highly  cohesive  systems.  Recent  efforts  such  as  UAS  Control  Segment 
(UCS)  Architecture,  The  Open  Group  Future  Airborne  Capability  Environment  (FACE™), 
OMS,  and  Acoustic  Rapid  Commercial-off-the-shelf  (COTS)  Insertion  (ARCI)  are  all  designed 
to  support  OSA.  However,  promoting  effective  competition  also  requires  an  open  business 
model. 

Independent  of  BBP,  the  DoD  OSA  policies  and  governance,  over  the  past  several  years,  have 
significantly  impacted  the  acquiring  of  weapon  system  products  and  processes.  In  reviewing  past 
actions  and  accomplishments,  the  discussion  must  be  viewed  from  both  an  acquisition  and  post- 
IOC  (deployment)  context.  From  the  acquisition  systems  engineering  perspective,  based  on  the 
utilization  of  broad-sweeping  Modular  Open  Systems  Architecture  (MOSA)/Naval  Open 
Architecture  (NOA)  principles,  one  could  state  that  DoD  stakeholders  have  achieved  an  excellent 
rating  of  “A+.”  However,  from  a  post-deployment  context  perspective,  whereby  the  Government 
can  fully  receive  fiscal  relief  due  to  competition,  the  rating  at  best  is  “fair/poor.”  So,  why  is  the 
Government  unable  to  receive  high  levels  of  return  on  investment  (ROI)  once  a  system  is 
deployed?  To  address  this  complex  subject,  numerous  factors  must  be  addressed,  some  of  which 
are  listed  below: 

•  Cultural  behavior  is  a  significant  contributor.  If  a  priority  scheme  were  established  to 
assess  which  MOSA/NOA  principles  are  important,  real  competition  at  the  deployment 
phase  would  rank  the  lowest.  Mission  performance,  acquisition  cost,  and  schedule  are  still 
the  primary  drivers  that  acquisition  program  managers  adhere  to. 

•  Industry  has  implemented  OSA  initiatives  primarily  from  a  corporate  enterprise 
commonality  and  productivity  perspective,  such  as  build  less,  maximize  reuse  through 
portability,  and  therefore,  sell  more.  OSA  attributes  can  be  used  to  gain  market  share 
locking-in  such  as  corporate  modularity,  corporate  selection  of  certain  standards  and 
corporate  frameworks,  and  common  product  lines.  These  elements  are  all  based  on 
commercial  COTS/open  software  products  and  processes.  These  attributes  are  often  used  to 
drive  down  operating  costs  and  provide  competitive  pricing  at  major  awards  events. 

•  The  DoD  has  difficulty  aligning  a  data  rights  strategy  with  a  SE  maturity  model.  The  end 
result  is  that  the  Government  limits  its  success  by  its  inability  to  fully  measure  what/when 
it  owns,  what  rights  it  has,  and  how  it  should  release  this  information  in  a  time-based 
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manner  to  ensure  that  real  competition  at  the  component  level  will  exist,  especially  during 
the  operational  and  support  (O&S)  phase. 

•  The  DoD  lacks  a  measurable  governance  model  for  consistent  and  repeatable  outcomes  for 
competition  based  on  OA.  Tools  such  as  the  MOSA  Program  Assessment  and  Rating  Tool 
(PART)/Open  Architecture  Assessment  Tool  (OAAT)  are  often  ineffective  since 
contractors  always  obtain  passing  grades  due  to  the  generic  nature  of  OSA  principles,  and 
little  to  no  emphasis  is  given  to  post-initial  Operations  Capability  (IOC)  ROI. 

The  current  tools  sets  do  not  consider  the  interaction  of  the  technology  with  the  environment  in 
which  they  exist,  namely  the  business  environment.  CCRL  complements  the  Technology 
Readiness  Level  (TRL),  a  metric  to  assess  technology  maturity,  with  component-level  metrics 
relating  to  integration,  interoperability  and  program  readiness  for  Component  Competition. 

As  stated  within  the  general  guidance  for  Area  5,  strategies  to  be  considered  include  “OSA  that 
enables  competition  for  upgrades,  acquisition  of  technical  data  packages,  and  competition  at  the 
subsystems  level.  At  the  Component  level,  the  prospect  of  a  development  program  for  a 
substitute  or  follow-on  product  can  create  indirect  competitive  pressure.”  It  is  within  the  realm  of 
the  “component  level”  decomposition  that  the  associated  business  and  technical  consideration 
must  be  carefully  and  thoughtfully  investigated.  For  an  open  and  free  competition  among 
suppliers,  the  acquisition  process  needs  to  balance  supplier  community  (size,  available  industry 
competency,  persistent  life  for  follow-on  contract,  etc.)  and  granularity  of  technical  specification 
(architecture,  interfaces,  standards,  etc.)  with  data  rights  and  intellectual  property. 

It  is  the  intent  of  the  proposed  CCRL  to  measure  maturity  levels  of  both  the  open  business 
model  and  the  technical  architecture.  The  definitions  of  technical  architecture  have  been  well 
studied;  however,  metrics  to  define  an  open  business  model  are  more  problematic.  CCRL 
leverages  concepts  of  social  networks  to  answer  or  at  least  study  open  business  model  issues  to 
measure  the  success  of  implementing  OSA  as  part  of  promoting  effective  competition. 

COMPLEX  ADAPTIVE  SYSTEMS 

Insight  to  systems  that  consist  of  many  interacting  components  and  hierarchies  lies  in 
understanding  complexity  theory.  SE  approaches  are  necessary  but  not  sufficient  to  deal  with  the 
complexity  of  modern  weapon  systems  and  respond  to  the  changing  needs  of  the  warfighters. 
Over  the  last  couple  of  decades,  a  body  of  work  based  on  mathematics  has  led  to  the  discipline  of 
nonlinear  dynamics  and  the  study  of  complex  adaptive  systems.  Complex  adaptive  systems  is  a 
new  approach  to  science  that  studies  how  relationships  between  parts  give  rise  to  the  collective 
behaviors  of  a  system  and  how  the  system  interacts  and  forms  relationships  with  its 
environment.12  The  term  complex  system  formally  refers  to  a  system  of  many  parts  which  are 
coupled  in  a  nonlinear  fashion.  Natural  complex  systems  are  modeled  using  the  mathematical 
techniques  of  dynamical  systems,  which  include  differential  equations,  difference  equations,  and 
maps.  The  insight  is  that  behavior  of  the  complex  system  is  influenced  by 

•  Interconnectedness  with  the  environment  and  itself 

•  Nonlinearity  of  coupling 

•  Applicability  of  the  principle  of  superposition  not  valid 

•  Emergence  of  system  properties  and  behaviors 

The  system  behavior  is  said  to  be  emergent  when  it  cannot  be  understood  simply  as  the  sum  of 
its  constituent  parts.  Emergent  behavior  involves  interactions  between  individual  components 
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that  yield  distinct  patterns  at  the  system  level.  Emergent  systems  have  group  level  outcomes  that 
cannot  be  understood  simply  as  the  superposition  of  their  constituent  parts;  instead,  emergent 
group  behavior  is  nonlinearly  related  to  individual  interactions.  Moreover,  just  as  individual 
actions  affect  group  outcomes,  group  outcomes  feedback  to  affect  individual  actions.  This 
coupling  between  the  microscopic  individual  level  and  the  macroscopic  group  level  makes  the 
model  of  emergent  behavior  useful  for  understanding  a  dynamic  marketplace  driven  by 
competition  that  leads  to  the  emergence  of  innovation  and  productivity  for  DoD  acquisition. 

A  key  insight  of  complex  adaptive  systems  has  been  an  appreciation  of  the  mechanism  of 
emergence.  Models  of  self-origination  show  how  systems  can  locally  adapt  to  a  critical  region  in 
which  the  global  properties  of  the  system  take  on  regular  behavior,  such  as  a  power-law 
distribution  of  event  sizes.  Such  ideas  are  likely  to  serve  as  fodder  for  explaining  various  social 
scaling  laws,  like  the  success  and  failure  of  open  source  software  (OSS)  projects.14 

In  a  complex  system,  it  is  not  possible  to  reduce  the  overall  behavior  of  the  system  to  a  set  of 
properties  characterizing  the  individual  components.  Furthermore,  interactions  produce 
properties  at  the  collective  level  that  are  simply  not  present  when  the  components  are  considered 
individually.  These  types  of  complex  systems,  specifically  CAS,  have  emergent  collective 
behavior  that  can  not  be  explained  by  sum  of  the  constituent  parts  or  by  superposition  principle. 
However,  the  evolutionary  models  to  study  emergent  behavior  provide  fascinating  insight  into 
observed  behavior  in  emergent  social  phenomena  from  the  perspective  of  evolution  by  natural 
selection.  Much  of  the  analysis  of  the  dynamics  is  focused  on  stable  equilibria  and  their 
bifurcations.  Random  (stochastic)  effects  play  a  crucial  role  in  the  vicinity  of  bifurcation  points 
in  a  decision  tree.  In  complexity  theory,  bifurcation  of  new  branches  of  solution  following  the 
instability  of  the  current  state  caused  by  nonlinearities  and  interaction  with  the  human  system 
generates  a  source  of  innovation  and  diversification.  This  endows  the  system  with  new  solutions. 

The  CAS  approach  considers  landscapes  (of  possible  solution)  in  which  the  various  elements 
interact  in  nonlinear  ways,  resulting  in  a  solution  space  with  many  peaks  and  valleys  where  each 
peak  represents  a  solution  branch  on  the  bifurcation  curve  (Figure  4).  Contribution  of  complex 
adaptive  social  systems  has  been  recognized  for  the  nonlinearities  and  interactions  that  lead  to  a 
search  across  these  peaks  and  valleys  for  a  collective  decision-making  dynamic.15 
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System  Is 
unpredictable 
and  Is  able  to 
self -organize 
Into  new 
stable  solution 
(emergent 
behavior) 


System  remains 
stable  under 
external  pressures 
to  change  (No  effect 
on  system 
behavior). 


System  shins 
between  multiple 
solutions  and 
exhibits  change 
due  to  external 
pressures. 


Figure  4.  Bifurcation  Generates  New  Decision  Points  and  Leads  to  Complexity  but  Also  Can  Serve 
as  Source  of  Innovation 

Social  Network  and  Evolutionary  Dynamics 

A  suitable  language  to  relate  emergence  in  CAS  to  the  dynamic  DoD  acquisition  and 
procurement  marketplace  is  found  in  the  study  of  the  evolutionary  dynamics  of  behavior  in  social 
networks.16  Our  main  thesis  is  that  institutions  such  as  the  DoD  serve  to  build  a  network  of 
actors,  with  individual  actions,  into  a  marketplace  with  desired  emergent  behavior.  The  notion  of 
institutionalization  can  be  a  set  of  rules,  conventions,  or  mechanisms  that  produce  a  pattern  of 
aggregate  behavior. 

The  description  of  the  marketplace  is  thus  reduced  to  a  network,  and  a  network  is  any 
collection  of  entities  in  which  some  pairs  are  connected  by  links,  as  shown  in  Figure  5. 
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Figure  5.  A  Graph  Is  Formed  by  Vertices  and  Edges  Connecting  the  Vertices. 

Connectedness  can  lead  to  very  complex  networks. 

The  study  of  these  networks  provides  key  insight  for  institutional  design  to  produce  a  self¬ 
regulating  marketplace  with  desired  results.  Depending  on  the  properties  of  the  network,  such  as 
the  total  number  of  links  connected  to  a  node,  a  network  can  exhibit  a  range  of  behavior — from  a 
very  rigid  or  static  network  to  a  chaotic  network  where  changing  a  node  or  a  link  completely 
alters  future  dynamics  of  the  network.  However,  some  networks  also  settle  into  relatively  few 
patterns  of  behavior  or  self-organized  criticality.  Such  critical  states  with  long-range  order  and 
independent  of  initial  conditions  are  said  to  be  “on  the  edge  of  chaos.”  These  systems  are  also 
adaptive  such  that  a  change  in  the  environment  causes  perturbations  to  the  system;  however,  the 
systems  reorganize  themselves  with  most  of  the  previous  characteristics.  A  network’s  behavior  is 
dependent  on  the  network  topology.  The  following  properties  are  generally  used  to  characterize 
networks: 

•  Degree  distribution  -  the  degree  of  a  node,  k,  is  the  total  number  of  links  connected  to  this 
node,  and  degree  distribution  is  the  relative  frequency  of  each  value  of  k  in  a  network. 

•  Diameter  -  maximum  number  of  links  traversed  for  communication  to  flow  from  one  node 
to  another  by  following  the  shortest  route  possible 

•  Cluster  -  set  of  all  nodes  connected  by  some  path 

•  Clustering  coefficient  -  of  a  node  is  the  ratio  of  the  number  of  links  to  the  total  number  of 
possible  links.  Clustering  coefficient  of  a  network  is  the  average  of  all  clustering 
coefficient  of  the  nodes. 

Studies  show  network  structures  with  a  high  cluster  coefficient  and  a  small  network  diameter 
are  found  in  a  wide  range  of  natural,  social,  or  collaborative  networks.17  These  networks  are 
called  scale-free  networks.  The  degree  distributions  for  these  networks  follow  a  power  law,  as  in 
complexity  theory.  The  robustness  properties  of  scale-free  networks  are  important  for  the  BBP 
marketplace  (open  business  model)  because  information  and  resources  can  easily  and  quickly 
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diffuse  through  the  network  even  as  nodes  continuously  join  and  leave  the  network  (under 
contract/out  of  contract).  In  addition,  scale-free  networks  are  robust  against  node  failures  and 
preserve  its  structure. 

A  look  at  social  networks  provides  us  with  insight  for  deriving  the  CCRL  metrics  for  open 
business  models  to  supplement  existing  measures  of  technical  architecture. 

Open  Source  Software  (OSS)  Development  Community 

Multiple  case  studies  have  looked  at  OSS  development  projects  and  network  structure  of  the 
open  source  community.17  Conventional  wisdom  is  that  open  source  development  produces  more 
bug-free  code,  is  faster,  and  is  more  innovative  and  responsive  to  the  user  needs.  OSS  projects 
are  self-organized  and  employ  rapid  code  evolution,  massive  peer  code  review,  and  rapid 
releases  of  prototype  code.17 

OSA  should  look  to  replicate  the  positive  aspects  of  OSS  by  moving  to  an  open  system 
architecture  paradigm.  Modular  software  architecture,  common  standards,  and  tools  are 
necessary  but  not  sufficient  to  explain  the  success  of  OSS.  OSS  communities  also  exhibit  scale- 
free  network  features  and  have  power-law  distributions  since  communities  are  self-organizing 
due  to  sequential  growth  and  preferential  attachment  (business  ties,  preferred  supplier  relation, 
etc.).  OSS  networks  tend  to  have  a  small  diameter  and  high  clustering  coefficient.  The  small 
distances  result  from  the  fact  that  a  member  can  participate  in  multiple  communities; 
furthermore,  large  numbers  of  members  participate  on  one  project  clustered  around  a  thought 
leader.  An  analysis  of  39,000  open  source  projects  hosted  at  SourceForge.net  involving  over 
33,000  developers  by  researchers  at  University  of  Notre  Dame  shows  that  open  source 
movement  is  not  a  random  graph  but  displays  preferential  attachment  of  new  nodes  (developers 
joining  projects).  These  networks  display  power-law  relationships  (shown  in  Figure  6)  due  to 
heavily  skewed  distributions  which  “typically  happens  under  situations  of  positive  feedback  or 
increasing  returns  and  is  sometimes  called  the  ‘rich-get-richer’  effect  or  the  ‘band-wagon’ 
effect”.  OSS  communities  are  organized  around  more  than  just  some  common  standards;  they 
are  driven  by  market  dynamics  due  to  self-selection  of  projects  by  developers  and  users.  The 
self-selection  drives  some  projects  to  grow  disproportionately  larger  than  predicted  by  random 
growth  and  leads  to  the  power-law  distribution.  Alternatively  as  shown  in  Stony  Brook 
University  study  that  the  age-old  adage  that  "success  breeds  success"  is  a  reality  even  in  the 
OSS  community. 


Number  of  Projects  with  n  Developers 


Number  of  Developers  on  p  Projects 


Figure  6.  Power-Law  Relationships:  OSS  Project  Size  and  Developer  Project  Membership  (Madey, 
Freeh,  &  Tynan,  2002) 
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A  competitive  DoD  marketplace  that  is  self-organizing,  adaptive,  and  agile  needs  more  than 
just  OSA,  but  must  also  be  engineered  to  support  a  dynamic  open  business  model. 

OPEN  ACQUISITION  MARKETPLACE  (OAM) 

A  dynamic  ecosystem  that  encourages  component  competition  requires  establishing  a 
framework  that  depicts  the  confluence  of  business  and  technical  drivers.  Part  of  establishing  a 
business  ecosystem  or  a  network  that  encourages  component  competition  is  to  foster  proper 
dynamics  between  the  business  (network  architecture)  and  the  technical  framework. 

An  open  and  free  competition  among  suppliers  fosters  forming  a  scale-free  supplier  network, 
as  observed  in  the  OSS  development  community.17  A  strategically  well-crafted  platfonn  ensures 
the  creation  of  common  architectural  constructs  and  related  automated  tools  to  develop  a  system 
structure/platform  that  is  based  on  commonality,  as  well  as  planned  variability. 1  Platforms  with 
well-defined  standards  for  both  structure  and  interfaces  promote  the  characteristic  of  reusability. 
Without  standards,  reuse  is  minimized.  Additionally,  the  structure  and  interface  standardization 
can  improve  system  developments.  For  example,  satellite  development  can  be  improved  by  using 
standard  interfaces  for  the  sensors  installed  on  the  satellite  bus.  This  allows  for  more  adaptability 
within  the  system.1  The  adaptability  is  a  key  foundation  for  realizing  capability  on  demand, 
which  allows  for  dynamic  composition  of  capabilities  with  standard  structure/interfaces. 

The  Internet,  the  most  successful  open  marketplace,  has  well-defined  open  standards  and 
platforms,  such  as  Internet  Protocol  Version  4  (IPV4)  and  associated  Internet  transport  and 
application  layer  protocols.  Especially,  IPV4  became  emergent  as  the  waist  (i.e.,  the  passing 
tube)  of  the  layered  hourglass  business/technical  architecture,  as  shown  in  Figure  7.  It  managed 
to  survive  the  intense  competition  with  other  similar  protocols,  including  Novell’s  Internetwork 
Packet  Exchange  (IPX),  the  X.25  network  protocol  used  in  Frame  Relay,  the  Asynchronous 
Transfer  Mode  (ATM)  network  layer  signaling  protocol,  and  several  others.  Then  it  became 
ossified,  surviving  much  longer  than  most  other  protocols,  while  providing  stability  to  the  entire 
Internet  ecosystem.  Of  course,  there  is  no  guarantee  that  IPV4  will  stay  forever.  Evolutionary 
force  has  and  will  continue  to  evolve  the  Internet’s  layered  hourglass  architecture. 


Figure  7.  An  (Incomplete)  Illustration  of  the  Hourglass  Internet  (Akhshabi  &  Dovrolis,  2011) 

One  of  the  notable  characteristics  of  the  architecture  is  that  the  lower  part  of  the  hourglass  is 
significantly  smaller  than  the  upper  part.19  This  is  an  emergent  property.  In  retrospect,  it  is 
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plainly  obvious  too.  Richer  opportunities  exist  at  high  layers,  where  applications  and  services’ 
market  flourish,  than  the  lower  layers,  which  mainly  deal  with  links  and  physical  layers.  The 
well-defined  IPV4  spurred  numerous  suppliers  who  produced  Internet-based  services  and 
applications,  and  eventually  made  a  key  contribution  to  the  creation  of  a  totally  new  and  highly 
diversified  and  agile  Internet  applications/services  industry.  One  of  the  keys  to  the  huge  success 
of  IPV4  is  that  it  was  neither  too  restrictive  to  discourage  new  entries,  nor  too  permissive  to 
create  incompatible  products  and  services. 

Our  goal  is  to  recreate  the  paradigm  of  the  layered  Internet  hourglass  architecture  in  the  DoD 
acquisition  market,  called  Open  Acquisition  Marketplace  (OAM).  Again,  the  role  of  the  waist  of 
the  OAM  is  paramount.  Our  current  conjecture  is  that  open  architecture  (OA),  common  platform, 
and  standards  are  excellent  candidates  for  forming  the  waist  (i.e.,  the  tunnel  tube)  of  the  OAM 
hourglass  architecture.  However,  there  is  a  small  difference  between  the  Internet  layered 
hourglass  architecture  and  the  layered  defense  OAM.  DoD  cannot  wait  indefinitely  until  a  proper 
waist  standard  is  emergent. 

Additionally,  most  commercial  products  don’t  support  an  infrastructure  that  has  a  product  life 
of  20-40  years,  therefore,  comparing  Android  apps  with  longer  term  DoD  apps  has  product 
sustainment  limitations.  Therefore,  the  DoD’s  OAM  must  be  driven  from  a  low-volume,  long¬ 
term  product  cycle-life  affordability  driven  perspective. 

Given  the  low  volume,  the  DoD  is  seeking  to  create  a  DoD  enterprise-driven  marketplace 
whereby  competing  organizations  can  buy  and  sell  their  state-of-the-art  products.  However,  too 
many  choices,  too  many  variations  of  the  infrastructure  could  dramatically  impact  the  success  of 
component  competition  and  defeat  the  ability  to  drive  down  costs.  Our  layered  OAM  must  offer 
some  levels  of  stability  to  withstand  turmoil  at  the  other  layers. 

New  challenges  will  emerge  regarding  infrastructure  not  so  much  from  a  research, 
development,  test,  and  evaluation  (RDT&E)  view  but  from  a  long-term  sustainment  objective. 
The  emerging  role  of  the  Government  will  change  from  a  capability-driven  organization  to 
include  component  competition  as  a  transactional  role-based  monitor. 

Carefully  devised  platforms,  open  standards,  and  data  rights  are  the  key  parameters  for 
success.  Standards  and  data  rights  need  to  be  exercised  at  key  locations  in  the  hourglass  to 
maximize  interoperability  and  drive  innovation.  A  choice  of  platfonn  and  standards  directly 
contributes  to  lowering  the  barrier  of  entries  and  fostering  competition  among  suppliers.  This 
rationale  warrants  the  Government  (or  a  consortium  composed  of  Government  and  industry 
partners)  to  take  adequate  ownership  (or  at  least,  a  critical  leadership)  of  crafting  and/or  selecting 
a  platform  and  standards.  It  is  not  necessary  to  “peanut  butter”  OA  and  data  rights  to  the  entire 
solution  stack.  Not  only  is  it  unnecessary,  but  it  may  be  detrimental  to  a  healthy  business 
ecosystem. 

Recent  efforts  such  as  UAS  Control  Segment  (UCS)  Architecture,  The  Open  Group  FACE, 
OMS,  and  ARCI  are  all  designed  to  support  OA,  which  is  well  aligned  to  support  the 
aforementioned  OAM.  The  remaining  question  is  how  well  these  OA  standards  are  actually 
performing  in  the  context  of  the  OAM,  while  creating  a  desirable  waist  effect  in  the  layered 
hourglass  OAM  architecture,  as  shown  in  Figure  8.  A  piloting  effort  in  an  actual  program 
context  is  proposed  in  the  context  of  a  real  acquisition  program. 
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Open  Acquisition 
Marketplace  (OAM) 

■  Measurable  robust  supplier 
network  (i.e.,  scale-free  supplier 
network) 

■  Adequate  incentives  and 
alignment  to  promote  good 
behavior 

■  Assurance  suppliers  are  not 
locked-in 

■  Aligned  with  platform-based 
product  family  development 

-  Layered  Bowtie/hourglass 
architecture 

■  Alignment  of  Data  Right  Strategy 
(DRS)  with  open  architecture 
Component  Competition  strategy. 

■  V&V  for  transparency 


Figure  8.  OAM  in  a  Construct  of  Layered  Hourglass  Architecture 

Product  Line  Architecture  (PLA)  has  not  been  well  utilized  by  the  DoD1.  PLAs  enable 
acceleration  of  delivery  of  technical  capabilities  to  win  an  unpredictable,  asymmetrical  war;  to 
prepare  for  an  uncertain  future;  and  to  reduce  the  cost,  acquisition  time,  and  risk  of  major 
defense  acquisition  programs1.  PLAs  are  open  architecture  with  published,  accepted  interfaces  to 
components  that  can  be  provided  by  different  vendors.  Thus,  PLA  naturally  encourages  new 
entries  of  suppliers,  and  creates  an  open  and  fair  competition  among  suppliers. 

Properly  aligned  Data  Right  Strategy  (DRS)  with  the  above  open  architecture  component 
competition  strategy  ensures  the  creation  of  a  purposeful  OAM.  Again,  periodic  verification  and 
validations  (V&Vs)  on  the  framework  discussed  above  should  provide  greater  confidence  that 
the  systems’  open  architecture  is  on  the  right  track  with  regard  to  promoting  a  component 
competition  ecosystem. 

COMPONENT  COMPETITION  READINESS  LEVEL  (CCRL)24 

CCRL  is  concerned  with  documentation  and  dissemination  program  roadmaps  to  drive  an 
open  acquisition  process  in  the  OAM,  to  provide  the  infrastructure  and  organization  for  system 
integration.  MIL-STD-881C  Work  Breakdown  Structure  (WBS)  was  used  to  provide  a  guide  for 
defining  the  top  three  levels  as  shown  in  Figure  9.  The  levels  are  as  follows: 

•  Level  0:  Goal 

-  Reduce  total  ownership  cost  through  agility  and  adaptability 

•  Level  1 :  Drivers 
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-  Technical  drivers  were  addressed  through  Open  Infrastructure  and  Roadmaps 

-  Business  drivers  were  addressed  through  Open  Acquisition  and  Organization 
•  Level  2:  Measurable  Objectives 

-  Inter-relationship  of  objectives  that  generate  a  complex  dynamic  behavior  resulting  in 
competition 


ACHIEVEMENT  #1:  BREAKDOWN  OF  COMPONENT  COMPETITION 
INTO  ELEMENTS  VIA  RELATIONSHIPS  (STATIC  VIEW) 


Post  IOC 
Competition 
©Component  Level 


Open  | 

Open 

Infrastructure  J 

Acquisition 
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Organization 


Figure  9.  Achieving  Competition  at  Component  Level  Requires  a  Balanced  Interplay  of  Business 
and  Technology  in  OAM 

Level  1:  Open  Infrastructure  Composition 

Open  infrastructure  requires  the  involvement  of  numerous  stakeholders  that  drive  the 
development  of  Interface  Technology  Requirements  via  three  measurable  objectives: 

•  Common  Data  Models 

•  Open  Application  Programming  Interface  (API) 

•  Open  Software  Development  Kits/Component  Development  Kits  (SDK/CDK) 

Level  2  defines  and  codifies  Interface  Technology  Requirements  that  include  all  components 
(the  application  layer,  transport  layer,  network  layer,  data  layer,  and  the  physical  layer)  and 
provide  for  a  Protocol  Requirements  and  Performance  Requirements.  Included  in  the  Interface 
Technology  Requirements  are  the  open  infrastructure  tasks  for  promoting  a  component 
competition  ecosystem  and  periodic  third  party  evaluations  and  assessments  to  judge  the 
openness  of  the  infrastructure.  In  this  technical  framework  infrastructure,  openness  is  not  as 
much  a  determination  of  whether  the  technology  is  an  industry  standard,  de  facto  standard,  etc., 
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but  it  is  more  whether  or  not  the  technology  is  available  to  all  of  the  organizations  that  want  to 
compete  and  contribute  modules  to  the  program  system. 

Along  with  the  SDK/CDK  and  its  associated  middleware,  key  components  and  their  key 
interfaces  should  be  identified.  These  components  and  interfaces  are  the  ones  that  implement  the 
feature/functionality  upgrades  in  the  aforementioned  system  capabilities  roadmap.  By 
designating  these  components  and  interfaces  as  key,  they  require  more  extensive  documentation 
and  stewardship  throughout  the  program  execution.  The  key  components,  standards,  and 
interfaces  should  be  identified  during  the  system  architecture  design  phase  and  maintained  for 
the  remainder  of  the  program  execution. 

Relying  on  all  of  the  organizations  contributing  to  a  program  to  integrate  their  modules  into 
the  greater  system  without  a  designated  program  test  bed  is  a  management  headache.  Therefore, 
it  is  important  for  the  program  to  have  an  integration  test  bed  with  which  all  contributing  teams 
integrate  their  components.  Otherwise,  integration  efforts  will  be  too  disjointed  to  be  effective. 

Finally,  a  third  party  assessment  team  should  review  the  technical  framework  infrastructure 
periodically  to  fulfill  the  V&V  phase.  An  assessment  should  provide  greater  confidence  that  the 
systems’  open  architecture  is  on  the  right  track  with  regard  to  promoting  a  component 
competition  ecosystem. 

Open  Infrastructure  Composition:  Common  Data  Model 

Anyone  who  has  designed,  developed,  and  integrated  a  sensor  processing  system  has 
encountered  the  challenge  of  matching  data  structures  and  data  types.  Writing  data  schema 
translators  as  part  of  component  and  external  interfaces  is  not  a  scalable  or  feasible  solution.  This 
is  especially  true  of  network-centric,  distributed  sensor  processing  systems.  In  these  systems  it  is 
important  for  all  of  the  participants  to  understand  and  agree  upon  what  types  of  data  are  being 
processed  in  the  system,  where  in  the  system  the  data  needs  to  be,  and  how  it  will  get  from  one 
node  to  another  in  the  distributed  system.  The  appropriate  solution  is  to  develop  a  common  data 
model  that  spans  the  system  and  ideally  is  compatible  with  the  data  model  across  the  enterprise. 
The  data  model  should  be  developed  before  Preliminary  Design  Review  (PDR),  and  it  should  be 
revised  as  needed  past  IOC. 

Aligning  data  right  strategy  with  data  model  elements  is  considered  essential.  There  are  two 
objectives,  interoperability  and  ownership.  If  the  Government  is  going  to  provide  affordability 
benefits  through  sharing,  then  the  terms  and  conditions  associated  with  the  shades  of  ownership 
and  data  content  must  be  discussed  as  a  team-driven  event — legal  (Intellectual  Property 
[IP]/Acquisition);  engineering  (Architecture/Subject  Matter  Experts);  managers 
(Program/Product  IPT/  Supplier  Chain),  and  contracts. 

Open  Infrastructure  Composition:  Open  API 

Given  that  a  weapon  system  contains  many  sub-components,  cards,  and  integrated  chips,  it  is 
essential  that  the  Government  develops  a  methodology  to  select  wisely  only  those  APIs  that  they 
consider  to  be  protected  for  competitiveness.  Therefore,  based  on  the  successful  identification  of 
key  components,  comes  the  ability  to  identify  corresponding  key  interfaces  (software  and 
hardware).  The  word  key  in  a  generic  term,  however,  from  a  MOSA  context  key  interfaces  are 
those  interfaces  that  are  related  to  components  that  are  changing  often  and  are  costly  to  change. 
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The  word  open  in  open  in  MOSA  needs  to  be  redefined  with  respect  to  competition  and  not 
tagged  with  the  loosely  used  term  such  as  widely-used  published  standards.  In  this  context  of 
competition,  APIs  are  considered  to  have  the  following  attributes: 

•  Complete  and  accurate  with  deviation  fully  disclosed 

-  MS-C  maturity — contains  any  last  minute  changes  due  to  test  and  evaluation  activities 

-  Updated  documentation  such  as  ICD,  IDD,  etc. 

•  Management  and  sustainment — adaptability,  agility  at  the  API 

-  API  modification  and  patching 

-  Tools  and  processes 

Open  Infrastructure  Composition:  Open  SDK/CDK 

In  the  past,  SDKs  have  been  well  known  and  understood  to  be  critical  enablers  in  support  of  a 
modular  interface  driven  system  approach.  The  discussion  as  to  whether  the  DoD  needs  to 
construct,  manage,  and  govern  CDKs  is  pending.  The  CDK  context  is  driven  from  a  modular 
application  perspective  with  tools  and  processes  to  enable  others  to  upgrade  components  via 
periodic  functional  upgrades,  similar  in  nature  with  apps  upgrades.  Not  all  competition  will 
require  CDKs.  It  depends  on  the  Component  Competition  roadmaps  and  associated  strategy.  The 
amount  of  agility  will  dictate  the  need  for  CDKs.  If  the  component  has  an  agile  evolution-based 
upgrades  strategy  with  constant  modifications  to  the  baseline  components  on  a  periodic  duty 
cycle,  then  CDKs  might  be  desired.  If  the  component  upgrade  path  supports  both  evolution  and 
major  upgrades  (disturbing  innovation)  making  previous  components  obsolete,  then  CDKs  may 
not  be  the  best  option. 

The  CDK  will  emerge  as  a  key  element  to  the  success  of  DoD  component  competition.  CDK 
can  be  used  to  create  a  complete  and  functional  model,  define  its  functional  requirements  API 
and  level  of  abstraction,  define  the  components,  and  define  all  the  input/output  (I/O)  (pins)  which 
are  made  visible  to  other  components.  CDK  must/will  contain  the  following  items,  but  not 
limited  to 

•  System/Model  Driven  Items 

-  Hands  on  Lab  (HOL)  and  Executable  Code 

-  Target  Description,  compliers,  memory  processors,  networks,  etc. 

-  Functional  and  System  Description  Tools 

•  Component  Based  Horizontal  and  Vertical  Integration  (Real  Time  [RT])  Requirements 

-  Latency  and  Hard/Soft/Best  Effort  RT  requirements 

A  key  part  of  a  program  SDK  to  CDK  interface  is  the  middleware.  Middleware  libraries  are 
any  library  that  abstracts  away  computational,  communication,  and/or  task  management  of  the 
underlying  operating  system  and  hardware  from  the  algorithms  and  applications.  To  the  greatest 
extent  possible,  all  algorithms  and  applications  for  the  program  should  only  call  the  program 
middleware  libraries;  the  algorithms  and  applications  should  not  make  direct  operating  system  or 
hardware  calls.  This  provides  a  more  portable  set  of  algorithms  and  applications.  If  a  certain 
operation  is  not  supported  in  the  current  program  middleware,  an  appropriate  middleware  library 
should  be  integrated  or  developed  so  as  to  abstract  that  functionality  from  being  called  directly 
from  the  algorithm  or  application.  The  small  performance  impact  of  inserting  a  middleware  call 
is  more  than  offset  by  the  portability  that  is  afforded  with  the  middleware.  The  SDK/CDK 
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includes  the  software  libraries  along  with  tutorial,  documentation,  etc.  It  could  even  include 
virtual  machine  builds  in  which  algorithms  and  applications  are  developed.  Work  on  the 
SDK/CDK  should  have  started  by  the  PDR,  and  a  usable  version  should  be  available  soon  after 
the  Critical  Design  Review  (CDR). 

Level  1:  Open  Acquisition  Composition 

The  approach  to  acquire  a  DoD  system  that  is  built  ground  up  for  component  competition, 
from  a  life  cycle  perspective,  is  considered  essential.  There  are  three  primary  business  drivers 
enablers,  considered  Level  2  items:  a)  V&V  for  transparency,  b)  proper  strategy  to  provide 
adequate  incentives  and  alignment  to  promote  good  behavior  of  the  willing  and  able,  and  c) 
assurance  that  after  system  deployment,  certain  suppliers  are  not  locked  in  for  the  life  of  a 
program. 

The  acquisition  strategy  should  be  aligned  with  a  modular  product  family  design.  The  common 
functions  (modules)  for  a  given  product  platform  have  the  governance  to  promote  reuse  across 
derivative  products.  Within  a  product  family,  a  collaboration,  communication,  and  continuous 
delivery  mechanism  is  established  to  promote  a  robust  network.  Finally,  a  third  party  assessment 
team  should  review  and  assess  the  health  of  the  ecosystem  using  metrics  defined  for  scale-free 
networks. 

Timing  of  events  demands  the  alignment  of  DRS  with  that  of  the  open  architecture  Component 
Competition  strategy.  Getting  Government  Purpose  Rights  (GPR)  or  Unlimited  Rights  or 
knowing  what  sub-elements  have  restricted  rights  must  be  transparent  to  all  interested  parties 
before  major  contract  awards.  If  components  are  labeled  incorrectly,  the  Government  must  take 
appropriate  and  timely  steps  to  challenge  such  stated  rights  to  ensure  proper  handling  and 
markings. 

In  the  open  acquisition  process,  all  efforts  should  be  made  to  isolate  all  vendor-specific  IP  and 
technology  in  specific  modules/components  for  a  derivative  product.  The  lock-in  of  suppliers 
from  a  long-term  perspective  often  prohibits  the  Government  and  prime  from  selecting 
components  from  third  parties.  The  prime/lead  systems  engineer  (LSI)  must  address  such  issues 
before  the  Materiel  Solution  Analysis  (MS-A)  phase  award.  They  must  recognize  this  challenge 
and  state  upfront  how  they  plan  to  ensure  competition.  Upon  entering  the  Technology 
Development  (TD)  phase,  the  challenges  will  be  understanding  what  and  what  not  to  open  and 
compete.  An  item  that  has  a  great  deal  of  agility  (rapid  number  of  changes  having  high  cost)  is 
best  suited  for  competition. 

Level  1:  Roadmaps  Composition 

Most  program  managers  are  familiar  with  the  technology  roadmaps  that  are  important  to  every 
program.  Technology  roadmaps  are  particularly  important  to  maintaining  component 
competition  in  programs  and  are  instrumental  for  defining  PLAs.  Program  managers  and  lead 
engineers  must  maintain  cognizance  of  the  technology  trends  in  industry  and  be  able  to  explain 
how  those  trends  will  impact  the  program.  The  PLA  should  be  addressed  soon  after  passing 
Milestone  A  (MS-A)  and  should  be  kept  up  to  date  with  periodic  updates  well  past  IOC. 

Along  with  the  PLA,  a  system  capabilities  roadmap  activity  is  equally  important.  Many 
technology-driven  programs  require  that  the  system  to  be  deployed  has  not  only  certain  features 
at  IOC,  but  also  subsequent  upgrades  to  the  IOC  system  to  address  evolving  threats.  It  is  the 
roadmap  of  the  IOC  features  and  feature  upgrades  that  is  critical  to  managing  the  openness  of  the 
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system  and  the  solution  platform  as  a  whole.  The  system  capabilities  roadmap  should  be 
developed  and  documented,  and  the  product  platform  identified. 

Level  1  Driver:  Organization  Composition 

The  prime/contractor  organization  must  implement  policy,  processes,  guidance,  tools,  and 
training.  The  processes  shall  outline  an  approach  to  implement  the  MOSA  and  NOA 
requirements  system  during  product  development.  This  area  demands  an  organization  to  change 
based  on  three  enablers,  considered  Level  2  items:  a)  top-down  and  bottoms-up  alignment,  b) 
infrastructure  information  and  data  models  through  a  centralized  process,  and  c)  a  greater 
enforcement  role  based  on  sound  business-technical  rationale. 

CCR  Assessments  (CCRAs)  are  established  with  trained  people  to  ensure  that  Government 
and  Industry  have  successfully  implemented  MOSA  and  NOA  principles.  The  frequency  and 
level  of  assessments  were  taken  into  consideration  leveraging  both  Face-to-Face  (F2F)  and 
WebEx  assessments  at  key  milestones  in  the  systems  acquisitions  life  cycle.  The  programs  will 
schedule  the  CCRAs  which  will  be  conducted  jointly  with  Government  and  Industry. 

Building  an  organization  for  component  competition  (buying  and  selling)  requires  a  work 
force  that  connects  numerous  actions  in  accordance  with  the  product  life-cycle  process  and  not 
solely  at  the  RDT&E  phase. 

Often  a  program  manager  will  assign  one  or  two  individuals  the  task  of  managing  OSA 
activities.  This  is  done  not  from  a  design  team  perspective,  but  more  from  a  systems  engineering 
verification  and  validation  process  perspective — what  is  needed  to  pass  a  milestone  decision 
authority?  Therefore,  the  general  workforce  doesn’t  always  fully  understand  nor  grasp  the  inter¬ 
relationship  and  consequences  of  mistimed  or  non-existent  actions. 

These  three  sub-areas  collectively  drive  an  organization  to  embrace  component  competition. 
The  outcome  creates  consistency  and/or  uniformity,  a  desired  common  workforce  belief.  The 
effects  must  be  addressed  from  a  top-down  and  bottoms-up  enterprise  initiative  that  offers  vast 
productivity,  behavioral,  and,  eventually,  cultural  benefits. 

The  Government  must  provide  CCR  training  and  certification,  which  will  be  made  available  to 
the  project  development  team.  If  component  competition  is  going  to  be  a  serious  contender  in  the 
DoD’s  future  business  acquisition  culture,  then  workforce  training  must  be  emphasized.  The 
workforce  must  recognize  the  complexities  of  competition,  act  in  a  timely  manner,  and  govern 
from  a  domain  enterprise  POV.  This  requires  a  series  of  inter-related  training  modules  to  ensure 
proper  content  and  context.  A  series  of  trust-but-verify  assessments  (question-and-answer  tests) 
must  also  be  implemented.  These  tests  should  not  be  tailored  from  a  “one-problem  and  one- 
solution”  mentality  but  from  an  inter-relationship  of  WBS  elements  that  produce  complex 
business  and  technical  effects.  Given  that  our  workforce  is  constantly  rotating,  the  frequency  of 
training  needs  to  be  conducted  at  every  post-milestone  decision  award.  For  example,  during  a 
pre  MS-A  award,  the  team  is  usually  small  but  experienced  in  the  area  of  “business  as  usual.” 
When  program  enters  an  EMD  phase,  the  composition  and  numbers  increase  greatly  and  training 
must  be  reapplied.  If  not,  components  that  were  circled  for  competition  at  PDR  can  quickly 
become  non-competitive  during  the  EMD  tasks  due  to  untrained,  unaware  individuals. 

Creating  a  centralized  infrastructure  that  is  shared  by  the  greater  community  is  a  critical 
enabler  for  OAM  that  supports  component  reuse  including  buying,  selling,  or  trading  of  new  and 
modified  components.  The  centralized  infrastructure  must  also  facilitate  full  disclosure  at  the 
interface  and  support  data  models  for  interoperability  layers  and  disclosure  of  any  hidden  IP  data 
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rights.  Paying  for  components  is  based  on  third  party  stakeholders  obtaining  needed  infonnation 
to  enable  them  to  compete  on  equal  footing.  The  process  must  be  established  based  on  fairness 
aimed  at  reducing  so-called  insider  trading. 

The  CCRAs  use  personality  bands  (PBs),  which  are  defined  within  the  acquisition  life  cycle 
and  are  aligned  with  the  Systems  Engineering  Technical  Reviews  (SETRs)  and  major 
milestones.  The  CCRAs  consist  of  five  F2F  meetings  to  assess  the  personality  band  (PB2,  PB4, 
PB6,  PB7,  and  PB9)  and  three  informal  Web-Ex  meetings  (PB3,  PB5,  and  PB8)  to  be  held 
during  the  acquisition  life  cycle,  as  shown  in  the  CCRA  Groupings  Chart  and  as  listed  in  Table  1 
below. 


Table  1.  CCRA  Assessment  and  Acquisition  Life-Cycle  Phase 


Acquisition  Life-Cycle  Phase 

Assessment  Type 

CCRA 

Technical  Maturity  (TM) 

F2F 

PB2 

TD 

Web-Ex 

PB3 

TD 

F2F 

PB4 

TD 

Web-Ex 

PB5 

TD 

F2F 

PB6 

EMD 

F2F 

PB7 

EMD 

Web-Ex 

PB8 

EMD 

F2F 

PB9 

CCRL  Implementation  via  an  Acquisition-Systems  Engineering  Process 

CCRL  defines  a  process  consisting  of  both  a  business  and  a  technical  framework  strategy.  As  a 
business  strategy  the  process  evaluates  the  appropriateness  and  feasibility  of  applying  scale-free 
networks  to  successfully  permit  component  competition  and  third-party  involvement.  The  CCRL 
process  for  development  programs  concentrates  on  life-cycle  affordability  and  managing  change 
as  part  of  the  overarching  business  strategy  by  decomposing  products  into  functions,  grouping 
common  functional  modules  into  a  common  product  platform,  and  choosing  standards  for 
interfaces  to  facilitate  addition,  removal,  and  substitution  of  modules.  Also  of  importance  is 
prioritizing  and  identifying  the  subsystems/modules  that  change  most  often  and  therefore  have 
the  greatest  impact  on  program  cost  over  its  life  cycle.  Using  the  Key  Open  Sub  System  (KOSS) 
the  program  can  determine  the  subsystems,  components,  relative  rate  of  change  over  the  life 
cycle,  cost  of  change,  and  relative  value  to  the  warfighter.  The  CCRL  process  provides  guidance 
for  the  program  to  document  the  hardware  and  software  open  system  architecture  design 
requirements  for  the  entire  program  development  effort  including  the  TM  (i.e.,  MS-A),  TD,  and 
EMD  Phases. 

The  CCRL  process  is  the  vehicle  for  interfacing  component  competition  into  the  systems 
engineering  (SE)  acquisition  process,  whereby  CCRL  activities  are  identified  and  enhance  the 
development  of  component  competition.  The  CCRL  process  goals  will  ensure  that  a  way  of 
measuring  the  “openness”  of  a  system  is  how  readily  a  system  component  can  be  replaced  with 
one  developed  by  a  different  vendor,  with  no  loss  in  overall  system  effectiveness.  The  CCRL 
process  adheres  to  the  principles  of  MOSA-NOA.  The  program  achievement  of  these  five 
principles  will  allow  qualified  third  parties  to  add,  modify,  replace,  remove,  or  provide  support 
for  a  component,  based  on  open  standards  and  published  interfaces.  Key  CCRL  criteria  can  be 
specified  for  each  of  the  system  engineering  phases  leading  up  to  a  major  program  milestone, 
and  it  is  important  to  establish  these  criteria  across  the  full  life  cycle  in  order  to  build  component 
competition  into  the  system. 
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MS-A  Phase 

During  the  MS-A  phase,  most  of  the  CCRL  related  activities,  criteria,  and  results  can  be 
mapped  to  content  of  the  MS-A  Program  Open  System  Management  Plan  (OSMP)  (see  Figure 
10).  Associated  MS-A  engineering  analyses  engineering  analysis,  which  includes  the  following: 

•  Establish  OSA  Training  Workforce 

•  Establish  OSA  Policy  &  Guidance 

•  Establish  a  Strategy  for  Unlocking  Vendors  at  a  Component  Level 

•  Establish  a  Data  Rights  Strategy 

•  Perform  Initial  Key  Open  Sub  Systems  (KOSS)  assessment,  the  process  which  defines 
subsystems/components  that  have  the  potential  to  yield  the  greatest  benefit  to  life-cycle 
affordability  by  applying  MOSA  principles 

•  Achieve  a  CCRL  of  2  by  Milestone  A 

•  Identify  product  platfonn  ecosystem  and  establish  node  connection  to  the  ecosystem 
network 

The  MS-A  Phase  provides  a  business  and  technical  approach  for  Modular  OSA  to  enable 
competition. 
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Figure  10.  MS-A  CCRL  Roadmap  with  Supporting  Processes 
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Technology  Development  (TD)  Phase 

During  the  TD  phase,  most  of  the  CCRL  related  activities,  criteria,  and  results  can  be  mapped 
to  content  of  the  Milestone  B  OSMP  (see  Figure  11).  Associated  TD  engineering  analyses  and 
OSMP  content  include  the  following: 

•  Systems  requirements  and  technology  development 

•  System  architecture  and  technology  demonstration 

•  Establishment  of  a  Long-Range  Volatility  Capabilities  Roadmap 

•  Performance  of  a  KOSS  Assessment  to  identify  components  for  competition 

•  Identification  of  Key  Interfaces  to  enable  Competition 

•  Alignment  of  a  Unified  Data  Model  Strategy,  Tools,  and  Process 

•  OSA  with  Component  Competition  Roadmap 

•  Achieve  a  CCRL  of  6  by  Milestone  B 


Figure  11.  TD  CCRL  Roadmap  with  Supporting  Processes 
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Engineering  and  Manufacturing  Development  (EMD)  Phase 

During  the  Engineering  and  Manufacturing  Development  (EMD)  phase,  most  of  the  CCRL 
related  activities,  criteria,  and  results  can  be  mapped  to  the  content  of  the  Milestone  C  Program 
OSMP  (see  Figure  12).  Associated  EMD  engineering  analyses  content  include  the  following: 

•  Provides  data  model/processes 

•  Addresses  testing  for  OSA  components 

•  Aligns  OSA  with  Component  Competition  Roadmap 

•  Achieves  a  CCRL  of  9  by  Milestone  C 


Figure  12.  EMD  CCRL  Roadmap  with  Supporting  Processes 
CCRL  Certification  and  Piloting 

CCRL  processes  have  to  be  designed  to  produce  verifiable  artifacts  that  can  be  used  to  certify 
compliance  as  shown  in  Table  2. 
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Table  2.  Representative  CCRL  Definition  and  Alignment  with  TRL 


TRL/CRL 

Rating 

DoD  Product  TRL  Definitions 

CCRL  Definitions 

1 

Basic  principles  observed  and  reported 

(New  platform)  Blank 

(Legacy  P31)  Technical  open  with  business  closed  (locked-in)  from 
Government’s  P0V 

2 

Technology  concept  and/or  application 
formulated 

Outline  an  open  competitive  business  strategy  and  product  platform  ecosystem 
(Min.  vendor  lock  and  initial  Data  Rights  Strategy) 

3 

Analytical  and  experimental  critical  function 
and/or  characteristic  proof  of  concept 

Establish  long-range  volatility  capabilities  (post  IOC)  roadmap 

4 

Component  and/or  breadboard  validation  in 
laboratory  environment 

Identify  components  (what  and  what  not)  to  compete 

AND 

Assess  system/architecture  in  support  of  competitive  ecosystem 

5 

Component  and/or  breadboard  validation  in 
relevant  environment 

Realign  revised  DRS  with  components  for  competition 

6 

System/subsystem  model  or  prototype 
demonstration  in  a  relevant  environment 

System/components  Data  Model  Strategy,  tools  and  process  established 

AND 

For  each  component  show  a  logical  flow  via  a  Component-to-System 
Competition  Roadmap 

7 

System  prototype  demonstration  in  an 
operational  environment 

System  prototype  mature  Data  Models 

AND 

Implement  a  System  V&V  competitive  environment 

8 

Actual  system  completed  and  qualified 
through  test  and  demonstration 

Actual  system  completed  and  releasable  SDK/CDK  for  all  components 

AND 

measure  diversity  of  supplier  ecosystem  for  competitiveness 

9 

Actual  system  proven  through  successful 
mission  operations 

Actual  systems  tested  for  competition  through  independent  V&V  of  SDK/CDK 

MS-A  TD  EMD 


The  next  step  is  to  pilot  the  CCRL  concept  with  the  above  CCRL  matrix.  A  program  in  a  TD 
phase  is  a  good  candidate  for  piloting.  By  collaborating  with  the  program  office,  first,  assess  the 
CCRL  level  as  it  is.  It  is  expected  that  the  CCRL  level  would  be  accessed  as  low  as  Level  1  or  2. 
Then,  following  the  progression  of  the  CCRL  matrix,  create  a  plan  that  lays  down  a  course  of 
action  to  raise  the  CCRL  level  to  6  or  higher  at  the  end  of  the  TD  phase.  The  first  step  is 
outlining  an  open  competitive  business  strategy  for  the  program,  and  laying  out  an  approach  to 
create  a  product  platform  ecosystem.  At  minimum,  this  initial  strategy  should  address  how  to 
avoid  a  vendor  lock  in  any  phases  of  the  program,  and  establish  a  proper  data  right  strategy, 
which  directly  supports  the  creation  of  an  OAM.  The  time  frame  of  this  strategy  ought  to  address 
both  the  IOC  and  post-IOC  period. 

Next,  identify  major  components  in  the  context  of  the  platform  chosen,  and  classify  them  into 
two  groups:  competing  and  non-competing  components  in  the  OAM  ecosystem.  Not  all 
components  need  to  be  competed.  They  must  be  examined  from  a  low-volume,  long-term, 
product  cycle-life  affordability  driven  perspective.  Most  commercial  products  don’t  support  an 
infrastructure  that  has  a  product  life  of  20-40  years.  The  goal  is  the  best  valued  OAM  ecosystem 
for  the  DoD,  while  preventing  programs  from  a  single  vendor  lock.  The  resulting  OAM 
ecosystem  is  expected  to  be  a  scale-free  network  with  desirable  agility  and  robustness. 

As  the  OAM  ecosystem  evolves,  DRS  needs  to  be  realigned  and  revised  to  reflect  the  latest 
OAM  ecosystem  landscape.  This  ensures  a  continual  evolutionary  progression  of  the  layered 
hourglass  OAM  architecture  by  encouraging  suppliers  remaining  in  the  market  to  continue 
competing,  while  luring  new  entries  in  the  OAM  ecosystem.  Also  critical  is  creating  or  fostering 
an  open  tool  vendor  market,  which  further  optimizes  the  OAM  ecosystem  by  reducing  the  cost  of 
producing  components.  Perhaps  the  most  critical  is  to  identify  candidate  OAs,  evaluate  in  a  real 
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program  execution  context,  and  narrow  down  to  a  single  open  architecture  that  enables  the 
formation  of  a  well-functioning  layered  hourglass  OAM  ecosystem.  Unmanned  aerial  system 
(UAS)  UCS  Architecture,  The  Open  Group  FACE,  OMS,  and  ARCI  are  some  examples  of  OAs 
designed  to  support  the  OAM  ecosystem.  Components,  tools,  DRS,  and  a  strategic  platform, 
along  with  carefully  chosen  standards  and  an  open  architecture,  complete  the  construction  of  the 
OAM  ecosystem. 

Fortunately,  the  CCRL  process  and  its  compliance  levels  are  not  completely  tangential  to  the 
DoDI  5000.02  acquisition  process.  One  great  integration  point  is  the  Acquisition  Strategy 
document,  which  is  one  of  the  documents  required  to  be  submitted  as  an  entry  condition  of 
Milestone  B  evaluation  by  the  Milestone  Decision  Authority  (MDA).19  For  example,  the  CCRL 
compliance  level  is  readily  included  in  the  Open  System  Approach  of  Acquisition  Approach 
section  of  the  Acquisition  Strategy  document.  Business  Strategy  and  Resource  Management 
sections  of  the  same  document  are  also  additional  anchor  points  to  integrate  the  CCRL  concept 
and  compliance  level. 

Out  of  the  first  piloting  effort  of  the  CCRL  concept  and  CCRL  compliance  matrix,  the 
effectiveness  of  the  CCRL  will  be  tested  and  evaluated  in  the  context  of  a  real  acquisition 
program.  All  lessoned  learned  will  be  documented  and  used  to  mature  the  CCRL  concept, 
matrix,  and  process. 

Additionally,  we  also  propose  a  research  effort  to  perform  a  qualitative  formulation  of  the 
scale-free  network  behavior  and  its  effect  in  the  OAM  ecosystem.  The  research  outcome  will 
greatly  improve  our  understanding  of  the  scale-free  network  behavior  in  an  OAM  ecosystem,  and 
provides  a  theoretical  underpinning  to  manage/manipulate  the  OAM  ecosystem. 

ACQUISITION  AT  THE  EDGE  OF  CHAOS 

SE  practices  have  become  stagnant.  They  were  designed  to  perform  tasks  accurately, 
predictably,  and  repeatedly,  but  not  to  continually  modify  their  behavior  in  reaction  to  a  dynamic 
environment  and  to  solve  a  range  of  problems.  In  the  language  of  complexity  theory,  current  SE 
and  the  supporting  acquisition  model  have  developed  to  support  a  steady  state  system  of  the  Cold 
War  world.  A  complementary  SE  and  acquisition  model  is  needed  for  the  world  faced  with  a 
dynamic  and  asymmetric  warfare  that  is  based  on  complex  adaptive  systems. 

The  CCRL  defines  and  measures  competition  readiness  at  the  component  level  to  promote 
agility  into  the  complex  dynamics  of  the  acquisition  processes.  CCRL  is  a  set  of  specific  OSA 
and  ecosystem  health  related  tasks.  Tasks  are  applied  to  the  capability-driven  acquisition 
model.20 

According  to  a  new  University  of  British  Columbia  study  published  in  the  Proceedings  of  the 
Royal  Academy,  social  connectedness  is  crucial  for  the  development  of  more  sophisticated 
technologies.  A  Stanford  University  study  has  also  suggested  that  social  networks  may  be 
contributing  to  increased  intelligence  among  the  young.  This  is  an  emergent  benefit  of  a  scale- 
free  network  behavior  in  social  networks. 

As  shown  by  OSS,  the  DoD  acquisition  model  needs  the  power  of  the  network  by  creating 
ecosystems  around  product  platforms  and  eliminating  closed-source  development  teams  in  favor 
of  communities  consisting  of  developers,  co-developers,  and  active  users.  Co-developers  and 
active  users  are  generally  not  part  of  a  closed  development  team  but  are  required  for  product 
innovation  process.  It  will  truly  instantiate  a  workable  framework  and  process  for  the  BBP 
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(http://bbp.dau.mil/)  of  the  Under  Secretary  of  Defense  for  Acquisition,  Technology,  and 
Logistics,  Honorable  Frank  Kendall. 
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Acronym 


Definition 

Application  Programming  Interface 
Acoustic  Rapid  COTS  Insertion 
Asynchronous  Transfer  Mode 
Better  Buying  Power 
Complex  Adaptive  Systems 
Component  Competition  Readiness 
CCR  Assessment 

Component  Competition  Readiness  Level 

Component  Development  Kit 

Critical  Design  Review 

Capability  on  Demand 

Commercial  Off  The  Shelf 

Department  of  Defense 

Data  Right  Strategy 

Engineering  Manufacturing  Demonstration 
Face-to-Face 

Future  Airborne  Capability  Environment 
Government  Purpose  Right 
Hands  on  Lab 
Input/Output 


API 

ARCI 

ATM 

BBP 

CAS 

CCR 

CCRA 

CCRL 

CDK 

CDR 

COD 

COTS 

DoD 

DRS 

EMD 

F2F 


FACE™ 


GPR 

HOL 

I/O 
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Acronym 

Definition 

IOC 

Initial  Operations  Capability 

IP 

Intellectual  Property 

IPV4 

Internet  Protocol  Version  4 

IPX 

Internetwork  Packet  Exchange 

JCIDS 

Joint  Capability  Integrated  Development  System 

KOSS 

Key  Open  Sub  System 

LSI 

Lead  Systems  Integrator 

M&S 

Modeling  and  Simulation 

MBE 

Model  Based  Engineering 

MDA 

Milestone  Decision  Authority 

MIL-STD 

Military  Standard 

MOSA 

Modular  Open  Systems  Architecture 

MS-A 

Milestone  A 

MS-B 

Milestone  B 

MS-C 

Milestone  C 

NDIA 

National  Defense  Industrial  Association 

NOA 

Navy  Open  Architecture 

O&S 

Operational  and  Support 

OA 

Open  Architecture 

OAM 

Open  Acquisition  Marketplace 

OAAT 

Open  Architecture  Assessment  Tool 

OMS 

Open  Mission  Systems 

OSA 

Open  Systems  Architecture 

OSMP 

Open  System  Management  Plan 

OSS 

Open  Source  Software 

PART 

Program  Assessment  and  Rating  Tool 

PB 

Personality  Band 

PBE 

Platform  Based  Engineering 

PDR 

Preliminary  Design  Review 

PLA 

Product  Line  Architecture 

POV 

Point  of  View 

RDT&E 

Research  Development  Test  and  Evaluation 

ROI 

Return  on  Investment 

RT 

Real  Time 

SDK/CDK 

Software  Development  Kit  /  Component  Development  Kit 

SE 

Systems  Engineering 

SOA 

Service  Oriented  Architecture 

TD 

Technology  Development 

TM 

Technology  Maturation 

TRL 

Technology  Readiness  Level 

UAS 

Unmanned  Aerial  System 

UCS 

UAS  Control  Segment 

USD  AT&L 

Under  Secretary  of  Defense  for  Acquisition,  Technology  and  Logistics 

V&V 

Verification  and  Validation 

WBS 

Work  Breakdown  Structure 
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